In general, Ethernet bridges are used to connect Ethernet local area network (LAN) segments in order to form a bridged LAN network (BLN). The Ethernet bridges interconnect the LAN segments such that from a terminal connected to a BLN, all other terminals connected to the BLN may be reached as if they are connected to the same LAN. In order to ensure that the bridges are interconnected in a loop-free topology, the bridges may run a spanning tree protocol (e.g., a virtual bridged LAN spanning tree protocol (IEEE 802.1Q-2004), a current rapid spanning tree protocol (IEEE 802.1D-2004), and like spanning tree protocols as known in the art). In general, such protocols determine whether associated ports of a bridge should be configured as blocking ports (i.e., no traffic is transmitted or received via this port) or forwarding ports (i.e., traffic may be transmitted and received via this port). By blocking ports to links that create a loop, the topology is guaranteed to be loop-free.
Unfortunately, in the process of changing a port state from blocking to forwarding (and, similarly, from forwarding to blocking), the port may enter various transient states. For example, in the IEEE 802.1D spanning tree protocol, a listening state and a learning state are defined. Furthermore, in addition to ensuring a loop-free topology, a spanning tree protocol may provide a protection topology in case of network failures (e.g., bridge failures, link failures, and the like). Since network failures typically lead to a loss of connectivity, a protection topology comprises another possible topology that restores connectivity. As such, existing spanning tree protocols will generally reconfigure from the disconnected topology to a connected topology (i.e., the protection topology).
Unfortunately, in existing spanning tree protocols, a particular spanning tree is used irrespective of the traffic load associated with that spanning tree, even though another spanning tree would result in improved network performance. Furthermore, existing spanning tree protocols render traffic engineering quite difficult, and provide network operators with only limited influence over the resulting spanning tree. For example, although existing spanning tree protocols allow link cost modifications, tracking the consequences of such changes is extremely complicated. Furthermore, if a network failure occurs, the resulting protection spanning tree is difficult for a network operator to predict. As such, existing spanning tree protocols do not support establishment of optimum spanning trees.